1. Field of the Invention
The present invention relates to a technique for creating a logical duplicate database (including a partial duplication) for an online database during online service hours in an online database system operating, for example, on a 24-hour basis.
2. Description of the Related Art
With the recent diversification of social needs, etc., the service hours of online transaction processing systems based on databases (hereinafter abbreviated DBs) have become progressively longer. Under such circumstances, processing operations have to be done within limited hours after the online service hours. Such processing operations may include various batch processing operations performed using information maintained in the DB, DB maintenance operations (DB reorganization operations involving arranging overflow data, changing the data storage structure, etc.), or DB backup operations (creating a duplicate DB to provide against DB failure). The need therefore arises for a system that allows these processing operations to be done simultaneously and in parallel fashion during the online service hours.
Among the above processing operations, online DB backup has been accomplished in the prior art by a method such as described below. FIGS. 14A and 14B are conceptual diagrams illustrating the DB backup process performed during online processing.
FIG. 14A illustrates in time series fashion how updates made to an online DB by transaction data (1) to (9) are recorded in a journal file. At the same time, the contents of the online DB are copied in units of blocks when the online DB is being updated with the transaction data (1) to (9).
In journal recording, the write process is initiated at the same time as the copying process. The information recorded at this time includes, for each block for which the online DB is updated, the block number, updated data, and the physical location (address) of the updated data from the start address of the block. These are collectively called physical update data.
The block mentioned here refers to the unit in which data is transferred for reading or writing between a main storage device and a secondary storage device such as a magnetic disk. Each block is assigned a sequential block number.
Journaling is completed at an arbitrary time after the end of the copying process, the purpose being to create a backup DB for the online DB at that time. Based on the earlier mentioned copy DB and on the DB update journal, in which the updates made to the online DB have been recorded, the backup DB is created in accordance with the procedure as shown in FIG. 14B.
First, information on the timing for copying the online DB for each block is compared with information on the timing for acquiring the result of the online DB updating with the transaction data as a DB update journal. After the completion of the copy operation, a selected DB update journal is created by selecting only the journals from which the DB update journals have been acquired.
Next, using the information recorded in the selected DB update journal, the copy DB is updated. In this manner, the results of the DB updating by the transaction data that occurred after the copying are reflected in the copy DB. Thus, the creation of the backup DB is accomplished.
In the above DB backup operation, processing is performed in units of blocks. Operations concerning the contents of the records (data storage structure) within each block are performed using only the physical position information of each record from the start address of the block. In other words, all processing is done by so-called physical data processing that has no regard to the contents. Accordingly, the backup DB created by the above method is exactly the same as the online DB in the data storage structure as well as in the physical arrangement of the records within each block.
The various batch processing operations and DB maintenance operations mentioned earlier are performed based on the thus created backup DB. While the above DB backup operation was performed by physical data processing, the batch processing and maintenance operations are performed based on the logical data structure. Such a logical data structure is shown in the specific example of the DB storage structure illustrated in FIG. 15.
More specifically, FIG. 15 shows a specific example of a customer DB (data set) used in a banking institution. In the upper part of FIG. 15 is shown the data structure of the DB which consists of a customer management record at the highest level, management records for customer's accounts such as ordinary savings and time savings at the next lower level, and transaction activity records for the respective savings accounts at the further lower level in an address chain fashion.
The lower part of FIG. 15 shows how the actual customer records organized in such a data structure are stored in a block of the data set. Though not shown in the figure, there is also an index field which stores the relationship between an entry key to each data record and its block number in the form of a table.
In the thus organized DB, when creating a separate DB by extracting only the records relating to the customer's ordinary savings account, for example, block X is first read into memory by the index field using the customer's code. Then, by tracing the address chain in the order of customer record 1, ordinary savings account management record 1, ordinary savings activity record 1, and ordinary saving activity record 2, only the desired records are selected and written to a separate DB to accomplish the purpose.
In this way, when performing processing based on the logical data structure, processing of the records is done based on the association between the records using the address chain information. This has the advantage of being able to accomplish the addition, deletion, etc., of records, independently of the physical location (address) of each record within the block. Hereinafter, performing processing based on such a logical data structure will be referred to as logical data processing, as contrasted with the earlier described physical data processing.
As described above, the prior art DB backup process performed during online processing is physical data processing which is based on the physical data structure treating each block as a unit. Because of this physical data processing, the duplicated backup DB and the online DB necessarily become the same in the data storage structure as well as in the physical arrangement of records within each block. Such processing therefore has had the problem that a duplicate DB cannot be created by extracting partial data. That is, a separate DB containing only the records relating to ordinary savings accounts retrieved from the customer DB, as illustrated in the above example, cannot be extracted during online processing.